Conversation
iaada
left a comment
There was a problem hiding this comment.
Revenant system is a mess but we don't need to fix it all at once. Fixing up corporeal is a good step forward.
| public virtual void OnApplied(Entity<CorporealStatusEffectComponent> ent, ref StatusEffectAppliedEvent args) | ||
| { | ||
| _appearance.SetData(uid, RevenantVisuals.Corporeal, true); | ||
| _appearance.SetData(args.Target, RevenantVisuals.Corporeal, true); |
There was a problem hiding this comment.
I feel the same way about the appearance data as I do the collision groups. I'd love to find a more generic solution but I'm drawing a blank.
There was a problem hiding this comment.
I'd prefer to leave it until the revenant system is refactored
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
iaada
left a comment
There was a problem hiding this comment.
These status effects are running into an issue I've failed to solve of setter functions conflicting with the expectation of having multiple status effects active. Status effects should be able to operate independently, but the setters require us to remember the original value in order for the entity to be reset.
My instinct is that the proper way to get around this is to use events to query for changes to visibility/collision, and to change these values only through subscriptions and raising the event through some RefreshValues() method. But that's a tall order given them being in engine, especially for physics.
I don't have a good answer. I feel like something will have to bend to preempt apparent bugs or major soaping.
| var ev = new RefreshVisibilityModifiersEvent(); | ||
| RaiseLocalEvent(ent, ref ev); |
There was a problem hiding this comment.
In this instance I'm not sure the value of an event over StatusEffectsSystem.EnumerateStatusEffects<T>(). The event doesn't seem likely to be used beyond the one subscription.
I think the ideal version might be an event in VisibilitySystem.RefreshVisibility() to get visibility changes instead of a setter API, but I need to think on that. I'm not sure there's an easy solution given that collision groups have a similar problem of using setters and conflicting with potential second or third statuses.
There was a problem hiding this comment.
I'll try to make a PR in the engine for VisibilitySystem later
Requires space-wizards/RobustToolbox#6539
About the PR
Converts
Corporealinto new status effects.Why / Balance
#38575
Technical details
Corporeal visibility is now handled through a refresh-based status effect flow instead of directly changing
VisibilityComponenton apply/remove. I addedVisibilityModifierStatusComponentwithaddVisibilityandremoveVisibilityfields so status effects define their visibility changes declaratively.VisibilityModifierStatusSystemrefreshes visibility by relayingRefreshVisibilityModifiersEventto all active status effects and recomputing the final mask from their combined modifiers. I also addedVisibilityModifierStatusTrackerComponentto preserve the baseline visibility between refreshes, andRevenantSystem.MakeVisible()now resets that baseline after manual visibility changes.StatusEffectCorporealuses the new component.Media
Requirements
Breaking changes
The
Corporealstatus effect has been removed and replaced withStatusEffectCorporealfor the new status effect system.The
CorporealComponenthas been removed and replaced withCorporealStatusEffectComponentChangelog